As is well known in the field of computer science, a virtual machine (VM) is a software abstraction—a “virtualization”—of an actual physical computer system. FIG. 1A shows one possible arrangement of computer system 700 that implements virtualization. VM 200 or “guest,” is installed on a “host platform,” or simply “host,” which includes system hardware 100, that is, a hardware platform, and one or more layers or co-resident components comprising system-level software, such as an operating system (OS) or similar software layer responsible for coordinating and mediating access to hardware resources.
As software, the code defining the VM will ultimately execute on the actual system hardware 100. As in almost all computers, this hardware will include one or more CPUs 110, some form of memory 130 (volatile or non-volatile), one or more storage devices such as one or more disks 140, and one or more devices 170, which may be integral or separate and removable.
In many existing virtualized systems, hardware processor(s) 110 are the same as in a non-virtualized computer with the same platform, for example, the Intel x-86 platform. Some hardware processors, however, have been developed to include specific hardware support for virtualization.
Each VM 200 will typically mimic the general structure of a physical computer and as such will usually have both virtual system hardware 201 and guest system software 202. The virtual system hardware typically includes at least one virtual CPU 210, virtual memory 230, at least one virtual disk 240 or similar virtualized mass storage device, and one or more virtual devices 270. Note that a disk—virtual 240 or physical 140—is also a “device,” but is usually considered separately because of the important role it plays. All of the virtual hardware components of the VM may be implemented in software to emulate corresponding physical components. The guest system software includes guest operating system (OS) 220 and drivers 224 as needed, for example, for the various virtual devices 270.
To permit computer systems to scale to larger numbers of concurrent threads, systems with multiple CPUs—physical or logical, or a combination—have been developed. One example is a symmetric multi-processor (SMP) system, which is available as an extension of the PC platform and from other vendors. Essentially, an SMP system is a hardware platform that connects multiple processors to a shared main memory and shared I/O devices. Yet another configuration is found in a so-called “multi-core” architecture, in which more than one physical CPU is fabricated on a single chip, with its own set of functional units (such as a floating-point unit and an arithmetic/logic unit ALU), and can execute threads independently; multi-core processors typically share only very limited resources, such as at least some cache. Still another technique that provides for simultaneous execution of multiple threads is referred to as “simultaneous multi-threading,” in which more than one logical CPU (hardware thread) operates simultaneously on a single chip, but in which the logical CPUs flexibly share not only one or more caches, but also some functional unit(s) and sometimes also the translation lookaside buffer (TLB).
Similarly, a single VM may (but need not) be configured with more than one virtualized physical and/or logical processor. By way of example, FIG. 1A illustrates multiple virtual processors 210, 211, . . . , 21m (VCPU0, VCPU1, . . . , VCPUm) within VM 200. Each virtualized processor in a VM may also be multi-core, or multi-threaded, or both, depending on the virtualization.
Applications 260 running on the VM will function essentially as they would if run on a “real” computer, even though the applications are running at least partially indirectly, that is, via virtual devices and processor(s). Executable files will be accessed by the guest OS from virtual disk 240 or virtual memory 230, which may be portions of the actual physical disk 140 or memory 130 allocated to that VM. Once an application is installed within the VM, the guest OS retrieves files from the virtual disk just as if the files had been pre-stored as the result of a conventional installation of the application. The design and operation of virtual machines in general are known in the field of computer science.
Some interface is generally required between the guest software within a VM and the various hardware components and devices in the underlying hardware platform. This interface—which may be referred to generally as “virtualization software” or “virtualization layer”—may include one or more software components and/or layers, possibly including one or more of the software components known in the field of virtual machine technology as “virtual machine monitors” (VMMs), “hypervisors,” or virtualization “kernels.” Because virtualization terminology has evolved over time and has not yet become fully standardized, these terms do not always provide clear distinctions between the software layers and components to which they refer. For example, the term “hypervisor” is often used to describe both a VMM and a kernel together, either as separate but cooperating components or with one or more VMMs incorporated wholly or partially into the kernel itself; however, the term “hypervisor” is sometimes used instead to mean some variant of a VMM alone, which interfaces with some other software layer(s) or component(s) to support the virtualization. Moreover, in some systems, some virtualization code is included in at least one “superior” VM to facilitate the operations of other VMs. Furthermore, specific software support for VMs is sometimes included in the host OS itself.
Unless otherwise indicated, embodiments of the invention described below may be used in virtualized computer systems having any type or configuration of virtualization software. Moreover, embodiments of the invention are described and illustrated below primarily as including one or more virtual machine monitors that appear as separate entities from other components of the virtualization software. This is only for the sake of simplicity and clarity and by way of illustration—as mentioned above, the distinctions are not always so clear-cut.
By way of illustration and example only, the FIGS. 1A and 1B show each VM running on a corresponding virtual machine monitor. The description's reference to VMMs is also merely by way of common example. A VMM is usually a software component that virtualizes at least one hardware resource of some physical platform, so as to export a hardware interface to the VM corresponding to the hardware the VM “thinks” it is running on. As FIG. 1A illustrates, a virtualized computer system may (and usually will) have more than one VM, each of which may be running on its own VMM.
The various virtualized hardware components in the VM, such as virtual CPU(s) 210, etc., virtual memory 230, virtual disk 240, and virtual device(s) 270, are shown as being part of VM 200 for the sake of conceptual simplicity. In actuality, these “components” are often implemented as software emulations included in some part of the virtualization software, such as the VMM. One advantage of such an arrangement is that the virtualization software may (but need not) be set up to expose “generic” devices, which facilitate, for example, migration of VM from one hardware platform to another.
Different systems may implement virtualization to different degrees—“virtualization” generally relates to a spectrum of definitions rather than to a bright line, and often reflects a design choice in respect to a trade-off between speed and efficiency on the one hand and isolation and universality on the other hand. For example, “full virtualization” is sometimes used to denote a system in which no software components of any form are included in the guest other than those that would be found in a non-virtualized computer; thus, the guest OS could be an off-the-shelf, commercially available OS with no components included specifically to support use in a virtualized environment.
In contrast, another term, which has yet to achieve a universally accepted definition, is “para-virtualization.” As the term implies, a “para-virtualized” system is not “fully” virtualized, but rather the guest is configured in some way to provide certain features that facilitate virtualization. For example, the guest in some para-virtualized systems is designed to avoid hard-to-virtualize operations and configurations, such as by avoiding certain privileged instructions, certain memory address ranges, etc. As another example, many para-virtualized systems include an interface within the guest that enables explicit calls to other components of the virtualization software. For some, the term para-virtualization implies that the guest OS (in particular, its kernel) is specifically designed to support such an interface. According to this view, having, for example, an off-the-shelf version of Microsoft Windows XP as the guest OS would not be consistent with the notion of para-virtualization. Others define para-virtualization more broadly to include any guest OS with any code that is specifically intended to provide information directly to the other virtualization software. According to this view, loading a module such as a driver designed to communicate with other virtualization components renders the system para-virtualized, even if the guest OS as such is an off-the-shelf, commercially available OS not specifically designed to support a virtualized computer system.
In addition to the distinction between full and partial (para-) virtualization, two arrangements of intermediate system-level software layer(s) are in general use as, or as part of, the virtualization software—a “hosted” configuration (illustrated in FIG. 1B) and a non-hosted configuration (illustrated in FIG. 1A). In a hosted virtualized computer system, an existing, general-purpose operating system forms a “host” OS that is used to perform certain input/output (I/O) operations, alongside and sometimes at the request and direction of a virtualization software component such as VMM 300. Host OS 420, which usually includes drivers 424 and supports applications 460 of its own, and the VMM (or similar component) are both able to directly access at least some of the same hardware resources, with conflicts being avoided by a context-switching mechanism. The Workstation product of VMware, Inc., of Palo Alto, Calif., is an example of a hosted, virtualized computer system, which is also explained in U.S. Pat. No. 6,496,847 (Bugnion, et al., “System and Method for Virtualizing Computer Systems,” 17 Dec. 2002).
In addition to device emulators 370, FIG. 1B also illustrates some of the other components that are also often included in the VMM of a virtualization system; many of these components are found in the VMM of a non-hosted system as well. For example, exception handlers 330 may be included to help context-switching (see again U.S. Pat. No. 6,496,847), and direct execution engine 310 and binary translator 320, often with associated translation cache 325, may be included to provide execution speed while still preventing the VM from directly executing certain privileged instructions in systems that do not otherwise provide such protection (see U.S. Pat. No. 6,397,242, Devine, et al., “Virtualization System Including a Virtual Machine Monitor for a Computer with a Segmented Architecture,” 28 May 2002).
In many cases, it may be beneficial to deploy VMMs on top of a software layer—kernel 600—constructed specifically to provide efficient support for the VMs. This configuration is frequently referred to as being “non-hosted.” Compared with a system in which VMMs (or other software components or layers with similar functionality) run directly on the hardware platform (such as shown in FIG. 1B), use of a kernel offers greater modularity and facilitates provision of services (for example, resource management) that extend across multiple virtual machines. Compared with a hosted deployment, a kernel may offer greater performance because it can be co-developed with the VMM and be optimized for the characteristics of a workload consisting primarily of VMs/VMMs. Kernel 600 also handles any other applications running on it that can be separately scheduled, as well as any temporary “console” operating system 420 that, in some systems, is included for such operations as booting the system as a whole or enabling certain user interactions with the kernel. The console OS in FIG. 1A may be of the same type as the host OS in FIG. 1B, which is why they are identically numbered—the main difference is the role they play (or are allowed to play, if any) once the virtualized computer system is loaded and running. One example of a non-hosted, virtualized computer system is described in U.S. Pat. No. 6,961,941 (Nelson, et al., “Computer Configuration for Resource Management in Systems Including a Virtual Machine,” 1 Nov. 2005).
As above, using virtual machine technology enables unstable or unsafe software to be isolated from a hardware state or system files necessary to run the physical hardware. While the physical hardware may be isolated from a program running on the virtual machine, the virtual machine itself might be vulnerable to malicious software, e.g., viruses or similar attacks.
In a code-injection attack, sometimes also referred to as an “arc-injection attack,” for example, an attacker exploits a vulnerability, e.g., a buffer overflow, to inject malicious code into a running application which then causes the injected code to be executed. In one example, a return-to-libc attack uses existing code for nefarious deeds. Buffer overrun examples include Slammer and Robert Morris' 1988 worm that exploited fingerd. The execution of the malicious code may allow the attacker to gain the privileges of the executing program or, generally, interfere with proper operations.
The “injection” of the malicious code may occur by changing return addresses or function pointers used in a program. One defense to such an attack is to check, at run-time, before a vulnerable instruction's execution, whether the destination address is allowed. As one example, one could enforce a policy that only allows return instructions to change the instruction pointer to an instruction preceded by a call instruction. A weaker variant of this policy is enforced by some operating systems, when run on NX-bit-enabled or similar hardware, by requesting that the CPU fault rather than execute an instruction from a “non-executable” page. There are other techniques, such as “whitelisting” that defend against many of the same exploits even on less capable hardware. “Whitelisting” requires that sequences of code to be executed are first checked against a pre-determined list of allowable sequences.
One drawback of known systems is that dynamic checks are expensive in terms of computation resources.
There are some CPUs, and binary translation systems, that contain a prediction mechanism that may be invoked when an indirect control-flow instruction (or the translation thereof) is executed.
U.S. Pat. No. 6,711,672 to Agesen, entitled “Method And System For Implementing Subroutine Calls And Returns In Binary Translation Sub-Systems Of Computers,” issued Mar. 23, 2004, assigned to the assignee of the present application, and incorporated herein by reference in its entirety, describes an implementation of return instructions in translated code. Agesen further discusses a prediction methodology within a virtual machine implementation and a system for predicting a destination of control-flow. If the destination is different from that which was predicted, Agesen proposes that the correct destination be recovered or an error declared.